-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: increase timeout in break-on-uncaught #10822
test: increase timeout in break-on-uncaught #10822
Conversation
setTimeout( | ||
assertHasPaused.bind(null, client), | ||
common.platformTimeout(3000) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @nodejs/testing
Might it be better to use a short setInterval()
(or a setTimeout()
that renews itself if the thing hasn't paused yet) and let the test time out via test.py
rather than having an AssertionError
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(That will also have the benefit of not requiring a minimum of 6 seconds for the test to run.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe like this?:
...
let interval;
function runTest(client) {
client.req(
{
command: 'setexceptionbreak',
arguments: {
type: 'uncaught',
enabled: true
}
},
function(error) {
assert.ifError(error);
client.on('exception', function(event) {
exceptions.push(event.body);
});
client.reqContinue(function(error) {
assert.ifError(error);
interval = setInterval(assertHasPaused.bind(null, client), 1);
});
}
);
}
function assertHasPaused(client) {
if (exceptions.length > 0) {
assert.strictEqual(exceptions.length, 1,
'debugger did not pause on exception');
assert.strictEqual(exceptions[0].uncaught, true);
assert.strictEqual(exceptions[0].script.name, testScript);
assert.strictEqual(exceptions[0].sourceLine + 1, throwsOnLine);
asserted = true;
client.reqContinue(assert.ifError);
clearInterval(interval);
}
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense. Tested locally as well. Thanks :-)
33d556f
to
a3c8ffd
Compare
@Trott Does this LGTY? |
}); | ||
} | ||
); | ||
} | ||
|
||
function assertHasPaused(client) { | ||
if (!exceptions.length) return; | ||
|
||
assert(exceptions.length, 'no exceptions thrown, race condition in test?'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm not mistaken, it's impossible for this assertion to fire given the check two lines above. So this line can probably be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a nit question/comment, but either way, LGTM if linter is green.
As the failures suggest, this test expects the uncaught exception to be thrown within 100 milliseconds, but on some of the test machines it takes longer than that limit to notify the exception. Thats why the test was failing. This patch polls every 10 ms to see if the exception is received.
a3c8ffd
to
bac94e6
Compare
@Trott I updated the PR with your suggestion. I'll land this today, if you have no objections. |
Landed in cc899a4 |
As the failures suggest, this test expects the uncaught exception to be thrown within 100 milliseconds, but on some of the test machines it takes longer than that limit to notify the exception. Thats why the test was failing. This patch polls every 10 ms to see if the exception is received. PR-URL: #10822 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
As the failures suggest, this test expects the uncaught exception to be thrown within 100 milliseconds, but on some of the test machines it takes longer than that limit to notify the exception. Thats why the test was failing. This patch polls every 10 ms to see if the exception is received. PR-URL: #10822 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
As the failures suggest, this test expects the uncaught exception to be thrown within 100 milliseconds, but on some of the test machines it takes longer than that limit to notify the exception. Thats why the test was failing. This patch polls every 10 ms to see if the exception is received. PR-URL: nodejs#10822 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
As the failures suggest, this test expects the uncaught exception to be thrown within 100 milliseconds, but on some of the test machines it takes longer than that limit to notify the exception. Thats why the test was failing. This patch polls every 10 ms to see if the exception is received. PR-URL: #10822 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
As the failures suggest, this test expects the uncaught exception to be thrown within 100 milliseconds, but on some of the test machines it takes longer than that limit to notify the exception. Thats why the test was failing. This patch polls every 10 ms to see if the exception is received. PR-URL: #10822 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
As the failures suggest, this test expects the uncaught exception to
be thrown within 100 milliseconds, but on some of the test machines it
takes longer than that limit to notify the exception. Thats why the
test was failing.
This patch increases the timeout to three seconds, with platform
specific timeout value.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test
Refer: #10456